REMARKS 



These remarks follow the order of the paragraphs of the office action. Relevant portions of the 
office action are shown indented and italicized. 

DETAILED ACTION 

Requirement of Information 

Applicant and the assignee of tins application are required under 3 7 ('PR P 105 to 
provide the fallowing information that the examiner has determined is reasonably 
necessary to the examination of this application 

This requirement for information is necessary to determine how the claimed 
invention differs from the "haste technique of this invention " in the prior art. 

Page 15 lines 1 2-19 of the instant application states "Par tons techniques have 
been known as systems for checking appropriateness of a privacy policy according to the 
present invention. Such techniques are also applicable to the present invention. More 
specifically, "IBM Corporation, IBM Tivoli Privacy Manager for e-business Planning 
Guide Version 1.1, July 2002 ' can be mentioned as a basic technique of this invention 
andean be incorporated in this invention as reference. " 

The examiner has located the referenced document and due to Us large size 
requests that the applicant point out which pages of the document best shows the basic 
technique of (he invention in the instant application. 

In response to this requirement, please state the specific improvements of the 
subject matter in claims 1-21 over the disclosed prior art and indicate the specific 
elements m the claimed subject matter that provide those improvements. For those claims 
expressed as means or steps plus function, please provide the spec fie page and hue 
numbers within the disclosure which describe the claimed structure and acts. 

In response, applicants respectfully state that reference referred to above, "Tivoli Privacy 
Manage.] 1 » e-Business Planning Guide Version .1.1," henceforth referred to as the "Tivoly 
reference", provides a system for checking appropriateness of a privacy policy. Page 9 of the 
Tivoiy reference reads, "[IJn addition to watching for the submission of information from 
information owners, a Tivoli Privacy Manager monitor watches for applications attempting to 
access privacy-sensitive fields in a monitored system. When an access attempt occurs, the 
monitor collects enough information to create an audit trail of the access. The monitor identifies 



DOCKET NUMBER:JP920030041USl 



2/8 



whose information is being accessed, its PI 1 type, who is accessing the information, arid the 
time that the access occurred and sends this information to the Tivoli Privacy Manager server. 
The server then locates the submission record corresponding to the information that was 
accessed and the governing privacy policy statement. Using the governing statement, the Tivoli 
Privacy Manager server makes a conformance check to determine if the access conformed to the 
governing privacy policy. Refer to "Conformance checking" on page 89 for a description of how 
conformance-check logic works." 

Page 89 of the Tivoly reference describes the term "Conformance checking", as "[Tjlie term 
conformance check is used throughout this guide to represent the process in which Tivoli 
Privacy Manager determines if a PI 1 access attempt does or does not conform to governing 
privacy policies." 

However, the solution of the Tivoly reference still has a potential problem on performance when 
the real-time conformance check is considered. The Tivoly reference page 9 further reads, 
"[Tjivoli Privacy Manager can enforce access to information in real-time. If real-time 
enforcement is set for a monitor, information accesses are blocked until the Tivoli Privacy 
Manager server determines if the access attempts conform to the rules of the governing policy." 

This implies the response time for information access is dependent on the response time for the 
conformance check performed by the Tivoli Privacy Manager server." As described in Figure 5 
of the Tivoly reference on page 1 0, the Monitored system server needs to ask the conformance to 
the Enterprise privacy server (i.e., Tivoli Privacy Manager Server) tor every request 
independently. This could be a bottleneck due to the latency of the network access and 
synchronous communication. 'The present invention avoids this problem by preparing the 
necessary information to locally determine if the access request conforms privacy policies. 

In general this application has two main ideas. 

1 . Precomputation and reuse of access authorization data (claim 1 ,6,12,15) 

2. Compression of those access authorization data. 
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The first is claimed in the claim 1 elements of the authorization engine and its authorization 
judgment unit. This is described variously in the specification summary and description of the 
invention. This particularly includes page 3, starting on line 7 through page 4, line 16; and page 
6, Sine 28 through page 8, line 7; and page 12, line 34, through page 13, line 13; and page 39, 
line 1, through page 42, line 12. 

The 'preliminary calculation unit' of claim 2 i s described variously in the specification 
description of the invention. This particularly includes page 13, lines 14-17; page 34, line 29 
through page 35, line 7; and page 37, line 1-12, and so on. 

The 'identi fication value' of claim 3 is described variously in the specification summary and 
description of the invention. This particularly includes page 3, lines 26-29; page 11, lines 16-18; 
and page 13 lines 19-21 and soon. 

The 'access authori zation data comprises a table which is generated i n advance' of claim 4 is 
described variously in the specification summary and description of the invention. This 
particularly includes page 3, lines 7-25; page 11, lines 7-14; and page .13 lines 14-21 and so on. 

The 'authorization list and a disapproval list' of claim 5 is described variously in the specification 
description of the invention. This particularly includes page 1 2, lines 22-28; page 1 3, lines 28- 
30; and page 27, lines 6-16 and so on. 

The locations for the elements in claim 6 are as shown for claim 1 and on page 1 3, line 3 1 
through page 14, line 5. 

The locations for the elements in claim 7 are as shown for claim 1 and on page 13, lines 14-21, 
The locations for the elements in claim 8 are as shown for claim I and on page .12, lines 1 1-33. 
The locations for the elements in claim 9 are as shown for claim 1 and on page 12, lines 22-2S. 
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The locations for the elements in claim 10 are as shown for claim 1 and on page 14, lines 9-14. 

The locations for the elements in claim II areas shown for claim 1 and on page 34, lines 15-28. 

The locations for the elements to claim 1.2 are as shown for claim 1 and various pages, starting 
on page 5, line 28. 

The locations for the elements in claim 13 are as shown for claim 1 and on page 12, lines 1 1-33. 

The locations for the elements in claim 14 are as shown for claim 1 and on page 3, lines 7-25; 
page 11, lines 7-14; and page 13 lines 14-21 and so on. 

The locations for the elements in claim 1 5 are as shown for claim I and on page 4, lines 3-16. 

The locations for the elements in claim 16 are as shown for claim I and on page 3, lines 26-29; 
page .11, lines 16-18; and page 13 lines .19-21 and so on. 

The locations for the elements in claim 17 are as shown for claim 1 and on page 3, lines 7-25; 
page 1 1 , lines 7-14; and page 13 lines 14-21 and so on. 

The locations for the elements in claim 1 8 are as shown for claim 1 and on page 45, lines 20-30. 

The locations for the elements in claim 19 are as shown for claim 1 and on page 45, line 33 to 
page 46 line 4. 

The locations for the elements in claim 20 are as shown for claim 6 and on page 45, line 33 to 
page 46 line 4. 

The locations for the elements in claim 21 are as shown for claim 12 and on page 45, line 33 to 
page 46 line 4. 
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A part of the idea of this invention includes three methods, 
fa) Compression along the access type axis (Starting in specification page 27, Sine 1 4) 
(h) Compression processing along the condition data axis ("Starting in specification, page 30, 

line 1) 

(c) Compression processing along the registrant axis (Starting in specification page 3 1, line 16) 
A basic idea of this is described in the fine 33, page 1.0. 

"In order to attain these, the invention focuses on the fact that privacy policies can be classified 
intoeiemen i « ing on. a poiiq setter and elements depending on registrants. The present 
invention is based on an idea that appropriateness checks with a registrant database using an 
authorization engine can be accelerated without degrading a security level, when it is 
possible to calculate access authorization data in advance and to adapt a calculated result 
to an access authorization by means of organizing the above-mentioned elements into 
independent fists or tables." 

The concrete idea consists of two description. 

The first idea is described from line 1 0, page 1 1 . This indicates precomputation and reuse of 
prior result. 

"In an access management method according to a example embodiment of the present invention, 
access types for access to a registrant database is decided by using the elements dependent on the 
policy setter divided into data usage type by the person in charge (a data user) in the policy 
setter, and a business purpose type, in this way, an access type list to be used as the access 
authorization data is generated and stored in a storage area in advance." 

The second idea is described from line 10, page 12. This indicates the compression method for 
the access authorization data decided prior to the access request. 
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"an access management method according to a second embodiment of the present invention uses 
access authorization date with a different configuration. The access authorization data 
includes an access type list generated by use of the data usage type and the business purpose 
type. The access authorization data used in the access management method according to the 
second embodiment of the present invention includes the access type list and a registrant 
condition table, in which elements of a policy setter ant! elements of the registrants are 
functionally separated at a higher level than the level in the above-described example 
embodiment Moreover, the access authorization data used in this access management method 
includes the registrant condition table in a format configured to exclude data not accessed 
from the access authorization data corresponding to the access type and belonging to the 
access type respectively. Simultaneously, in the access management method according to the 
second embodiment of the present invention, h is possible to use a so-called compressed 
registrant condition table in addition to an authorization list where everything is 
authorized to be accessed and a disapproval list where everything is disapproved to be 
accessed. It is possible to compress the registrant condition table configured according to the 
second embodiment of the present invention based on a prescribed rule for a condition agreed by 
the registrant upon registration. Accordingly, the registrant condition table can achieve high 
speed while securing a high security level." 

It is anticipated that this response satisfies the requirements, and brings the application to 
allowance of claims 1-21 . Favorable action is respectfully solicited, hi the unlikely event that 
any claim remains rejected, please contact the undersigned as required by the MPEP, by phone 
in order to discuss the application. 

Please charge any fee necessary to enter this paper to deposit account 50-05 10. 

Respectfully submitted. 

By: /Louis Herzberg, 

Dr. Louis P. Herzberg 
Reg. No. 41,500 
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Voice Tel. (845) 352-3194 
Fax. (845) 352-3 194 

3 Cloverdale Lane 
Mousey, NY 10952 



Customer Number- 54856 
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